OPPOSITE The Russian-built 
Zarya nears the Space Shuttle 
Endeavour during the carefully 
choreographed dance before 
their rendezvous. 


The Concept Review had not gone well, and my entire team was in the dumps. 

It took months for them to stop feeling lousy about their work and 
themselves. Not exactly a fun place to be in for me, the project manager, as 
we headed into the next review. 

At the heart of the problem was the review itself. We had tried to cram 
too much information into only three days. The review panel was inundated 
with so much information that by the end of the process, anyone — no matter 
how well they understood the project — would be cross-eyed. Detailed follow- 
up questions during the presentation pushed the review into overtime, and 
no one ever had the opportunity to talk with the expert engineers about the 
particulars of the project. 

I told my supervisor that I would like to have some control over how the 
next review was done. She was supportive. She saw how poorly the Concept 
Review had gone, and the impact it had on the team's morale. We all wanted 
to make our Preliminary Design Review better for everybody, both project 
team and reviewers. 
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ASKing the right person for help 

A couple of weeks later, my supervisor came to me and 
said, "Read this article and let me know what you think." 
It was a story in ASK Magazine about reviews by Marty 
Davis, a project manager at Goddard Space Flight 
Center. I read the article and thought I could apply his 
concepts to my project, so I gave him a call to get more 
information and to discuss my ideas with him. 

I got hold of Marty in his office and told him what 
had happened with our review. "Well, you don't want 
that," he said, laughing. 1 pitched some ideas, and he 
listened and told me what he had done to improve the 

I firmly believe that a review should 
be beneficial for both the panel and, 
more importantly, the project. 

reviews on his project. He affirmed my own feeling 
that the project manager has to he involved in the 
selection of the review board. This doesn't mean that 
the panel is going to be less independent, or that 
you're trying to hide a problem. It means that you’re 
looking for particular expertise. He encouraged me to 
be forceful. "This can best be handled by presenting 
the benefits to making this change," Marty told me. 
And so that is what I did. 

Taking charge 

Following Marty’s lead, I asked for input before assem- 
bling the new review board. I called around, and 1 got 
wonderful support from management. My supervisor 
began looking around for potential reviewers, as did my 
program manager. 

My program manager identified the person who 
ended up being chair of the review board. 1 called and 
spoke with him to find out if he was interested in 
working on the board. He had more than 25 years of 
experience with hardware similar to my project. He 
understood what it took to take a flight project from 
concept to design and through development. I told him 
how much this would mean to our team to have him as 
the chair, and he said he would be delighted. 

I went back to my division chief and said, "Here's 
the charge to the review panel. This is what they arc 
going to review, and here are the reviewers." He looked 




at my review plan and was pleased with the results. I 
wanted a panel with handpicked expertise and manage- 
ment approval, and that's what 1 got. 

Taking another page out of Marty Davis's playbook, 

1 decided to be flexible and try to think of new ways to 
streamline things. I didn't plan to do things exactly like 
Marty had. His project was orders of magnitude larger 
than mine. Mine was a microscope, and his an entire 
satellite. What I liked about his approach, and what I 
thought 1 could adapt to my own project, was what he 
did at the system level. I le kept the system level review 
focused on the higher order issues. If the review panel 
had subsystem questions, sure they could ask them, 
but if the questions started to get too detailed, then 
Marty stepped in and said, "Let's have a one-on-one 
about this tomorrow." 

I tailored my review similarly in that I had two sets 
of reviews, one for each subsystem, and then one for 
the system. It was amazing how well it worked. At the 
subsystem level, 1 blocked out two weeks of time and 
tried to keep it as informal as possible. It was formal 
from the standpoint that there was an attendance 
sheet, a written report, and a presentation at the system 
level, but it was informal once the reviewers got into 
the room. They would come in and sit around a table 
and have a dialogue with the engineers. The engineers 
could show the reviewers hardware, show them test 
data, and the reviewers could ask anything they 
wanted. At the system level, the reviewers stayed 
focused during the presentation, and had the 
subsystem review reports as additional data. The 
second day was reserved for reviewers to discuss 
detailed questions with the technical experts. 

Reviewing the reviews 

I firmly believe that a review should be beneficial for 
both the panel and, more importantly, the project. A 
crucially important aspect of the project life cycle is the 
independent evaluation of a project’s readiness to 
proceed to the next phase. Reviews should be looked 
upon as an opportunity, not a dreadful experience. 

Having the right reviewers on the panel is 
important, but I can't emphasize enough the impor- 
tance of one-on-one communication. It was Marty's 
experience that Requests for Action (RFAs) are often 
written because of a basic misunderstanding on the 
part of the reviewer. One-on-one communication can 
reduce that risk. If we can get reviewers to understand 
our position and if they still disagree with our 
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approach, then fine, write the RFA, but first let both 
parties come to an understanding of the issues. 
Additionally, if there is an issue, reviewers' recommen- 
dations can be discussed and understood by the project 
team at the time of the review. 

Addressing an inappropriate RFA is a waste of 
my time, a waste of the engineer's time, and a waste 
of the reviewer's time. The review board did write 
RFAs, but many others were not written because of 
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> > Saving half a million dollars is 
hardly something to shrug off. 
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the one-on-one sessions with the technical people on 
the project. With every comment that the review 
panel made, they gave us valuable suggestions. The 
whole board, by the way, recommended that we go 
forward with the design. 

We spent a significant amount of time and effort 
dealing with the RFAs from the first review. The second 
review, by comparison, was much more streamlined 
and effective. 

I estimate that the first review cost the project 


$700,000. The second review about $200,000. Reviews 
are expensive and time consuming — but they should 
also be beneficial. If you can refine the process and tailor 
it to best serve your system, your project will reap 
benefits. Saving half a million dollars, after all, is hardly 
something to shrug off. • 

Lessons 

• People within large organizations have probably 
already dealt with problems similar to the problems that 
you face; you can save time and money by taking 
advantage of that experience and knowledge. 

• Knowledge sharing by mentors can empower less 
experienced managers who would otherwise not 
challenge the status quo. 

• Reviews should encourage joint problem solving 
rather than just reporting. To accomplish this, ensure 
that the review process is viewed as feedback from 
independent and supportive experts. 

Question 

The review process has two objectives: control for external 
stakeholders and internal sponsors; and learning by 
providing real-time feedback to the team. How canyon share 
this learning with the rest of your organization and not 
intrude on the intimacy that exists between the reviewers and 
the project team ? 
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